fix: SCIM reconciliation fixes and diagnostic logging#65
Conversation
Temporary debug logs at each decision point in the reconciliation chain: - auth.ts: log final group list and scimEnabled flag - group-mappings.ts: log loaded mappings, desired state, existing members
Greptile SummaryThis PR adds four Key observations:
Confidence Score: 4/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[OIDC Callback] --> B[Extract groups from token claim]
B --> C{SCIM enabled?}
C -->|Yes| D[Load SCIM group memberships from DB]
D --> E[Union of SCIM groups and token groups]
C -->|No| F[Use token groups directly]
E --> G[LOG: final groups list]
F --> G
G --> H[reconcileUserTeamMemberships]
H --> I[Load all group mappings from SystemSettings]
I --> J[LOG: userId + userGroups + full mappings dump]
J --> K[Compute desired team roles map]
K --> L[LOG: desired roles]
L --> M[Fetch existing group-mapped memberships from DB]
M --> N[LOG: existing members]
N --> O[Diff desired vs existing]
O --> P[Create new memberships]
O --> Q[Update changed roles]
O --> R[Delete stale memberships]
Last reviewed commit: 3fa3341 |
| userGroupNames: string[], | ||
| ): Promise<void> { | ||
| const allMappings = await loadGroupMappings(); | ||
| console.log(`[reconcile] userId=${userId}, userGroups=${JSON.stringify(userGroupNames)}, mappings=${JSON.stringify(allMappings)}`); |
There was a problem hiding this comment.
Full system-wide RBAC config dumped on every reconcile call
allMappings contains every group-to-team mapping in the system — not just the ones relevant to this user. This function is called on every SSO login and on every SCIM group membership change, so in a busy deployment you'll get a full dump of your entire RBAC configuration in the logs on each event.
Two considerations:
- Verbosity: in a deployment with many SCIM users this will generate very noisy logs and make the entries you actually care about harder to find.
- Scope of exposure: server logs that contain the full mapping table (all teamIds, group names, and assigned roles) represent a broader blast radius if log storage is ever misconfigured or accessed by the wrong party, compared to logging only the subset of mappings that matched the current user's groups.
Consider scoping the log to the mappings that actually matched this user:
const matchedMappings = allMappings.filter(m => userGroupNames.includes(m.group));
console.log(`[reconcile] userId=${userId}, userGroups=${JSON.stringify(userGroupNames)}, matchedMappings=${JSON.stringify(matchedMappings)}`);This still reveals which mappings fired and which groups matched, giving you all the diagnostic signal you need without dumping the full config table every time.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/server/services/group-mappings.ts
Line: 59
Comment:
**Full system-wide RBAC config dumped on every reconcile call**
`allMappings` contains every group-to-team mapping in the system — not just the ones relevant to this user. This function is called on every SSO login *and* on every SCIM group membership change, so in a busy deployment you'll get a full dump of your entire RBAC configuration in the logs on each event.
Two considerations:
1. **Verbosity**: in a deployment with many SCIM users this will generate very noisy logs and make the entries you actually care about harder to find.
2. **Scope of exposure**: server logs that contain the full mapping table (all teamIds, group names, and assigned roles) represent a broader blast radius if log storage is ever misconfigured or accessed by the wrong party, compared to logging only the subset of mappings that matched the current user's groups.
Consider scoping the log to the mappings that actually matched this user:
```typescript
const matchedMappings = allMappings.filter(m => userGroupNames.includes(m.group));
console.log(`[reconcile] userId=${userId}, userGroups=${JSON.stringify(userGroupNames)}, matchedMappings=${JSON.stringify(matchedMappings)}`);
```
This still reveals which mappings fired and which groups matched, giving you all the diagnostic signal you need without dumping the full config table every time.
How can I resolve this? If you propose a fix, please make it concise.
Summary
Context
After merging PR #64 (SCIM reconciliation redesign), SSO login with OIDC+SCIM enabled is still not mapping users to their groups. Since the deployment is remote, these logs will reveal exactly where the chain breaks.
What to look for in logs
[oidc] User <email> groups (claim "groups"): [...]— groups from OIDC token[oidc] User <email> scimEnabled=true, final groups: [...]— after SCIM union[reconcile] userId=..., userGroups=[...], mappings=[...]— loaded mappings config[reconcile] desiredTeamRoles=[...]— computed desired state[reconcile] existing group_mapping members=[...]— current DB stateTest plan
[oidc]and[reconcile]entries